本系列拆解企業導入 AI／Agent 時，工具明明做完了，工作卻沒有因此變好的決策現場。

Day 04：Prompt 變長，常常不是因為模型不夠聰明，而是工作條件還沒有被拆開。

新工程師接手這個 RCA Agent 的第一天，只接到一個小修改。

把報告裡的「可能原因」改成「初步判斷」，再多一欄建議處理方式。

他打開 Prompt 檔案，右側捲軸只剩短短一截。

incident_analysis_prompt_v19.md
3,846 words
Last modified: 3 days ago

前面是角色設定、分析目標、輸入資料和輸出格式。後面則是一條接一條的限制。

若 Log 出現 timeout，不得直接判定為網路問題。
若相同錯誤曾在七日內發生，優先列出歷史處理方式。
若版本資訊與知識庫不一致，以使用者提供的版本為準。
除非有明確證據，不得將權限錯誤列為第一順位原因。
若事件發生於部署後三十分鐘內，需考慮版本變更因素。

旁邊還留著幾句註解。

# 2026-03：避免再次誤判 Batch Job
# 2026-05：主管要求不得使用「系統故障」
# 不要刪，之前刪掉後 Regression 會 Fail

新工程師在群組裡問：

「這幾條看起來有重複，可以先合併嗎？」

原維護者回得很快。

先不要動。每一句都有原因。

「原因記在哪裡？」

過了一會才有人說：

大部分在以前的測試紀錄。先保留就對了。

他最後只改了輸出欄位。測試案例全過。

直到值班工程師貼進一份新的 Log。

這一條規則，少的不是文字

Agent 判斷是上游服務連線逾時，建議先確認網路狀態與服務健康度。

值班工程師看完說：「方向不對。這是更新韌體後第一次開機，要先看版本有沒有真的切過去。」

新工程師回頭看輸入資料。裡面只有錯誤時間，沒有部署紀錄，也沒有版本切換狀態。

值班工程師打開另一個內部頁面。

「昨晚有更新排程。看到這個時間，我們本來就會先查版本。」

專案經理說：「那就在 Prompt 裡加一條。更新後發生錯誤時，優先檢查版本。」

架構師問：「但 Agent 現在拿不到更新排程。」

第一階段沒有 Connector，也沒有欄位能表示這台機器是否剛更新過。最後團隊仍然先補了一句：

若事件可能發生於系統更新後，請提醒使用者確認實際版本。

Prompt 從 3,846 個字變成 3,901 個字。

下一個案例，Agent 又把權限錯誤判成帳號設定問題。值班工程師說，這個專案多半是新建測試環境沒有完成初始化。

於是又加了一條：

若事件發生於新建測試環境，需先確認環境初始化狀態。

問題立刻又回來了：Agent 怎麼知道這是不是新建環境？

每次輸出不對，團隊都找得到一個合理的補丁。舊案例也真的會在下一輪 Regression 測試通過。

但補上的不是模型能力，而是本來就不在輸入裡的前提。

資深工程師知道的，未必已經是規格

人做 RCA 時，很多判斷不會被當成步驟。

看到發生時間，他會想到前一晚有部署；看到專案名稱，知道它有特殊測試環境；看到同一段錯誤訊息，會先排除過去遇過的假警報。

這些不是憑空猜測，而是工作現場累積下來的關聯。但如果團隊問「你怎麼判斷」，得到的往往只有一句「看情況」。

因為對資深的人來說，那些資訊本來就在畫面、記憶或另一個系統裡。他不需要把每個前提說出來，還是能往下走。

Agent 做不到這件事。

它看不到更新排程，就不知道版本切換是優先路徑；沒有環境資訊，就無法區分帳號設定和初始化失敗。它能根據已知內容產生一個看起來合理的答案，卻不能替團隊補上沒提供的事實。

所以 Prompt 一直長，常常不是 Prompt 寫得不夠完整。

而是它被迫承擔了原本不該由一段文字承擔的東西。

一份 Prompt 被拿來當了五種文件

這份檔案裡混在一起的內容，至少有五種：

• 必要輸入：分析前一定要有的資料
• 判斷規則：可描述、可測試的條件
• 例外範圍：只適用特定專案、環境或版本的規則
• 輸出格式：每次報告必須包含的項目
• 經驗與修正紀錄：某次事故為何這樣處理

它們的管理方式本來就不同。

缺少部署紀錄，是輸入問題，不是判斷規則。某個專案的新建環境容易漏初始化，是有適用範圍的例外，不該變成所有案件的通則。某次 Regression 過不了，則需要能回頭追到對應案例，而不是只在 Prompt 留下「不要刪」。

全部塞在同一段自然語言裡，後來維護的人只有一種安全做法：再加一句。

久了以後，檔案會保留每一次出錯的痕跡，卻不保留規則的來源、適用條件和淘汰時機。沒人敢刪，不代表它很完整；通常只代表整體已經沒人能解釋。

先分流，再決定 Prompt 要留下什麼

這種情況下，直接要求「優化 Prompt」通常只會得到一份更短、但同樣難維護的文字。

先把每一條內容分到對應位置，才能知道真正缺的是什麼：

如果資料拿不到，答案不一定是再補一條規則。有時候要新增欄位或 Connector；有時候要讓 Agent 先追問；有些情況則應直接交回人工判斷。

這不是退步，而是把 Agent 的可做範圍講清楚。

Agent 第一次沒有直接給答案

團隊沒有立刻重寫那份 Prompt。他們先改了提交 Log 的入口。

除了 Log，使用者還要選擇執行環境、實際版本，以及事件前是否有部署或設定變更。不知道可以填「未知」，但 Agent 必須說明這會影響哪一段判斷。

下一次測試，使用者只貼了一段錯誤訊息。

畫面沒有再列三個可能原因。

目前缺少：
- 執行環境
- 實際系統版本
- 事件發生前的變更紀錄

以上資訊會影響版本不一致與環境初始化的判斷。
請補充後再繼續分析。

專案經理看著畫面說：「以前至少會先給一個答案。」

新工程師說：「以前是先替我們猜一個答案。」

那份 incident_analysis_prompt_v19.md 沒有被刪掉，只被移到 Archive。

最後一行仍然留在裡面：

遇到未涵蓋的情境時，請根據現有資訊與專業經驗，做出最合理的判斷。

這句話沒有錯。它只是直到最後，都還沒有被拆成任何人可以執行的規格。